One Commit per Logical Change

Question:

How Often to Commit

Since you can choose when to make a commit, you might be wondering how often to commit your changes. It's usually a good idea to keep commits small. As the diff between two versions gets bigger, it gets harder to understand and less useful. However, you don’t want to make your commits too small either. If you always save a commit every time you change a line of code, your history will be harder to read since it will have a huge number of commits over a short time period.

A good rule of thumb is to make one commit per logical change. For example, if you fixed a typo, then fixed a bug in a separate part of the file, you should use one commit for each change since they are logically separate. If you do this, each commit will have one purpose that can be easily understood. Git allows you to write a short message explaining what was changed in each commit, and that message will be more useful if each commit has a single logical change.

Commit Size Quiz

To get some practice thinking about how often to commit, on the next screen, mark whether you think the following would be good commit sizes. If not, indicate whether you think this commit is too small and you’d like to wait and commit later, or whether you think it’s too big and you would have committed earlier. This is subjective, so there aren’t any definite right or wrong answers, but just choose the answer you think is best in each case.

You commit all the changes required to add a new feature, which you’ve been working on for a week. You haven’t committed since you started working on it.
You find three typos in your README. You fix and commit the first.
You commit all the changes required to add a new feature, which you’ve been working on for an hour.
You fix two small bugs in different functions and commit them both at once.

Start Quiz:

Solution:

One Commit per Logical Change Solution

You commit all the changes required to add a new feature, which you’ve been working on for a week. You haven’t committed since you started working on it.

This commit seems too big. It's easier to understand what each commit does if each only does one thing and is fairly small. Going a week without committing is not the best idea.

You found three typos in your README. You fix and commit the first.

This commit seems too small. It would be better to fix all three typos, then commit. That way, your history won't get too cluttered with typo fixes. Plus, you don’t need to worry about introducing bugs to a README, so bundling changes together is more likely to be a good idea.

You commit all the changes required to add a new feature, which you’ve been working on for an hour.

This is probably a good size for a commit. All the work is on a single feature, so the commit will have a clear logical purpose. After an hour, the diff will probably have a fair amount of content in it, but not too much to understand.

On the other hand, sometimes after working for an hour you’ll have run into more than one natural committing point, in which case you would want to break the feature up into smaller commits. Because of this, “too big” could also be a reasonable answer here.

You fix two small bugs in different functions and commit them both at once.

This commit is probably too big. It would have been better to commit after the first bug fix, since the two bug fixes aren't related to each other.

Judgment Call

Choosing when to commit is a judgment call, and it's not always cut-and-dried. When choosing whether to commit, just keep in mind that each commit should have one clear, logical purpose, and you should never do too much work without committing.

INSTRUCTOR NOTE:

What is a README?

Many projects contain a file named "README" that gives a general description of what the project does and how to use it. It's often a good idea to read this file before doing anything with the project, so the file is given this name to make users more likely to read it.